home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20020314-20021006 / 000049_ishikawa@yk.rim.or.jp_Sat Apr 27 10:48:43 EDT 2002.msg < prev    next >
Text File  |  2002-10-06  |  8KB  |  184 lines

  1. Article: 13340 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!phl-feed.news.verio.net!iad-feed.news.verio.net!iad-peer.news.verio.net!news.verio.net!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!newsfeed.media.kyoto-u.ac.jp!newsfeed.rim.or.jp!news.rim.or.jp!not-for-mail
  3. From: Ishikawa <ishikawa@yk.rim.or.jp>
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: a bug on GNU/linux: speed reset to unintended value occasionally.
  6. Date: Sat, 27 Apr 2002 10:49:21 +0900
  7. Organization: Ye 'Ol Disorganized NNTPCache groupie
  8. Lines: 160
  9. Message-ID: <3CCA03A1.59EF10C9@yk.rim.or.jp>
  10. References: <3CAFF81C.8039CBF8@yk.rim.or.jp> <3CC84CA6.D49F85EC@yk.rim.or.jp> <aa9l3h$4s4$1@watsol.cc.columbia.edu> <3CC98FC0.AADA5130@yk.rim.or.jp> <aac6cv$rlm$1@watsol.cc.columbia.edu>
  11. NNTP-Posting-Host: pl940.nas911.n-yokohama.nttpc.ne.jp
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=iso-2022-jp
  14. Content-Transfer-Encoding: 7bit
  15. X-Trace: news.rim.or.jp 1019872163 43612 210.139.42.172 (27 Apr 2002 01:49:23 GMT)
  16. X-Complaints-To: root@rim.or.jp
  17. NNTP-Posting-Date: Sat, 27 Apr 2002 01:49:23 +0000 (UTC)
  18. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18 i686)
  19. X-Accept-Language: ja, en
  20. Cache-Post-Path: duron!unknown@localhost
  21. X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/)
  22. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13340
  23.  
  24. Frank da Cruz wrote:
  25.  
  26. > : I remember Fujii-san from KEK helped
  27. > : the popularization of Kermit on Japanese PC.
  28. > :
  29. > Yes, the NEC PC-9801.  This was in the pre-Windows days, when PCs
  30. > ran only DOS (or very early forms of Unix).  I found it quite
  31. > amazing.  The keyboard driver -- which lets you type Romaji, puts up
  32. > little menus, learns from you, guesses which Kanji you mean, etc --
  33. > seemed to be about 100 times more powerful than the PC itself :-)
  34. Oh, those were the days. I used to get a kick out of
  35. showing these features in one of our home-brew programs at the office
  36. to visiting overseas dignitaries
  37. and hearing the "Oh" and "Wow".
  38.  
  39.  
  40. > Fujii-san wrote a book, "MS-Kermit Nyumon":
  41. >   http://www.columbia.edu/kermit/manuals.html
  42. > About the PC-9801 version of MS-DOS Kermit.  I suppose this is now a
  43. > rare collector's item.
  44. Yes, it is. The next time I see it at a second hand book store,
  45. I will grab it right away.
  46.  
  47. >  It is definitely the thinnest of all Kermit
  48. > books.  An advantage of Japanese writing: you don't have to use as
  49. > much paper!
  50. Until seeing the page, I didn't know books in languages other than
  51. in English and Japanese existed. Kermit, the program, seems to
  52. be used all over the world!
  53.  
  54. >   http://www.columbia.edu/kermit/k95faq.html (third item)
  55.  
  56. Product naming is full of pitfalls. I understand.
  57.  
  58. > : Anyway, below is the result of
  59. > : a little experiment I did to clear up
  60. > : my understanding of some options, etc..
  61. > : Hope some people might find this useful.
  62.  
  63. > So Cases 1 and 2 are the same, but "set control unprefix all" is a
  64. > bit faster than "set unprefix none".  OK, I believe it.  Both
  65. > commands work on the same table, but perhaps over the years the code
  66. > for the two commands has gotten slightly out of sync.  It might well
  67. > be that prefixing or not prefixing just one certain character (such
  68. > as NUL, ASCII 0) can make a significant difference in this case,
  69. > since executable binaries tend contain lots of NULs.  Maybe that's
  70. > the difference between the two commands.
  71.     ... 
  72. > I'll make a note to fix between the two unprefixing command in the
  73. > next release.
  74.  
  75. Thank you for studying the data.
  76. To give you some more data point,
  77. I did one more experiment. [This is going to be the final test result
  78. until probably the next year when I need to
  79. use Kermit on a different platform and use different feature :-) ]
  80.  
  81. Based on your observation that the executable wermit may have skewed
  82. distribution of octet values (very likely indeed), I counted the
  83. frequency of each octet value.  To make a long story short, I found
  84. that 0 is most frequent as you guessed correctly.
  85.  
  86. In the data below, value:frequency pairs are shown.
  87.  
  88. ishikawa@duron$ ./count < wermit
  89. 0:500744 1:14331 2:7721 3:6147 4:12153 5:13718 6:6117 7:8356 
  90. ********  Almost 1/4 of the total!!!
  91. 8:94806 9:4413 10:6944 11:2882 12:6407 13:3256 14:2521 15:18694 
  92. 16:16293 17:3848 18:7288 19:2430 20:4744 21:4601 22:6197 23:4869 
  93. 24:3524 25:2223 26:2685 27:5758 28:7488 29:8009 30:3761 31:20317 
  94. 32:80939 33:6472 34:2670 35:4321 36:4350 37:7897 38:6274 39:3488 
  95. 40:5673 41:3466 42:1745 43:1952 44:4746 45:4373 46:6375 47:2859 
  96. 48:4359 49:4954 50:2970 51:1510 52:2852 53:7989 54:1523 55:1883 
  97.     ...
  98.  
  99. Of the approximately 2MB ( 2183313 bytes to be exact), close to
  100. one fourth (1/4) is byte with value 0!
  101.  
  102. So again, I got curious and created a gzipped file from wermit.
  103.                 cp wermit /tmp/wermit
  104. ishikawa@duron$ gzip --best -v /tmp/wermit
  105. /tmp/wermit:     63.3% -- replaced with /tmp/wermit.gz
  106. ishikawa@duron$ ls -l /tmp/wermit*
  107. -rwxr-xr-x    1 ishikawa users      800501 Apr 27 10:26 /tmp/wermit.gz*
  108.  
  109. Why compression?
  110. Since compressed file usually have more balanced, close to uniform
  111. byte value distribution, I tried sending the compressed file and
  112. measured CPS to see if the uniform distirbution 
  113. closes the gap between observed CPS values in case-3 and case-4. 
  114. (The uniformity is like this. It is indeed very good.
  115. ishikawa@duron$ ./count < /tmp/wermit.gz
  116. 0:2903 1:3066 2:2973 3:3186 4:2985 5:2881 6:3127 7:3284 
  117. 8:2993 9:3010 10:2990 11:2996 12:2944 13:3282 14:3016 15:3456 
  118. 16:2729 17:2907 18:2784 19:3009 20:2820 21:2889 22:3073 23:3147 
  119. 24:2945 25:3013 26:3033 27:3129 28:2889 29:3015 30:3113 31:3700 
  120. 32:2844 33:2866 34:2722 35:3060 36:2838 37:2790 38:2891 39:3220 
  121. 40:2948 41:2901 42:2798 43:3017 44:3006 45:3199 46:2923 47:3343 
  122.     ...
  123.  
  124.  
  125. The new CPS values are shown below
  126. appended to the original table.
  127.  
  128.  
  129. >CPS (measured into 20% of the transfer. The file is 2183313 bytes.)
  130. >============================================================================
  131. >CPS:      case-1  case-2   case-3  case-4
  132. >---------------------------------------------------------------------------
  133. >send:    3010     3009    3835    3621
  134. >receive: 2973     2972       3786    3568
  135.  
  136. CPS measured for compressed wermit file. (wermit.gz)
  137. I only measurement for case-3 and case-4.
  138. (Also, the measurement was done into 50% (approximately 400KB) 
  139. of transfer.)
  140.                            case-3  case-4
  141.                            3796    3721    
  142.                            3753    3702
  143. ===========================================================================
  144.  
  145.  
  146. So as you have again correctly guessed, the skewed distribution of
  147. octet values (0 being dominant) had something to with the CPS under
  148. different control/prefix setting, i.e., "set control unprefixed all"
  149. vs "set prefixing none".
  150. With the uniform distribution of octet values, the difference
  151. decreases very much.  (So maybe the code path is indeed similar(?) and
  152. has not diverged very much??? The slight difference about 50 could be
  153. indeed a statistical fluke, but... )
  154.  
  155. Hope this helps.
  156.  
  157. Thank you again for the great support.
  158.  
  159. Always hoping to send back feedback to improve KERMIT.
  160.  
  161. Ishikawa, Chiaki
  162.  
  163. PS:
  164.  
  165. >case-4: `case-1` setting 
  166. >    +  "set prefixing none"
  167. >    (BTW, Completion doesn't show "none" as a valid third argument.)
  168.  
  169. I noticed a few cases where an accepted option is not shown in the
  170. response to "?" completion helper listing.  The above is such a case.
  171. I found the effect of "minimal" and "none" is slightly
  172. different and so "none" ought to be listed IMHO.
  173.  
  174. To wit,
  175. (/home/ishikawa/KERMIT/new-kermit/receive/) C-Kermit>set prefixing ?
  176. control-character prefixing option, one of the following:
  177.  all       cautious  minimal
  178. (/home/ishikawa/KERMIT/new-kermit/receive/) C-Kermit>set prefixing
  179.